The present invention relates to the provision of virtual private network (VPN) services through carrier networks such as Metropolitan Area Networks (MANs) or Wide Area Networks (WANs).
A VPN emulates a private network over public or shared infrastructures. When the shared infrastructure is an IP network such as the Internet, the VPN can be based on an IP tunneling mechanism, as described in Request For Comments (RFC) 2764 published in February 2000 by the Internet Engineering Task Force (IETF). Another approach, more particularly concerned by the present invention, provides link layer connectivity for the devices affiliated to the VPN.
Traditional WAN data layer 2 services provided by carriers are based on the virtual circuit or virtual connection concept. Data units are switched within the carrier network along pre-established trails referred to as virtual connections. These data units are for instance packets in X.25 networks, frames in Frame Relay (FR) networks, cells in Asynchronous Transfer Mode (ATM) networks, . . . The carrier network may also have a Multi-Protocol Label Switching (MPLS) architecture built over an infrastructure supporting a connectionless network layer protocol such as IP. MPLS is described in RFC 3031 published in January 2001 by the IETF. The virtual connections within a MPLS network are referred to as Label Switched Paths (LSPs).
The virtual connections can be pre-established by a configuration process, called xe2x80x9cprovisioningxe2x80x9d, performed by the network operator: they are then called Permanent Virtual Circuits (PVC). Alternatively, they can be established dynamically on request from the customer equipment: they are then called Switched Virtual Circuits (SVC).
Providing a SVC service puts constraints on both the Provider Edge (PE) and the Customer Edge (CE) devices. Both must support a common signaling set-up protocol such as, e.g., the ATM Q.2931 signaling protocol for ATM switched networks. Signaling protocols are complex, they induce additional costs (equipment costs, operational costs . . . ) and they may cause interoperability problems. Inadequate operation of one CE may block a PE and hence interrupt the service for several other customers. Most of the time, higher-level protocols and applications have not been designed to properly drive such SVC signaling, and it is necessary to develop sub-optimal emulation modes (for instance LAN emulation, classical IP , . . . ). These issues can explain why SVC services have been so seldom deployed for FR and ATM networks.
On the other hand, providing a PVC service requires an agreement between the provider and the customer regarding the endpoints of each virtual connection. Then it requires provisioning of each virtual connection by the provider. Often, it also requires additional provisioning by the customer in the CE device, unless some special signaling allows CE devices to automatically discover the virtual connections. In any case, these provisioning actions must be performed coherently between the provider and his customers, and they are a potential source of problems.
Recently, several vendors have been promoting Ethernet as a universal access media for LAN, MAN and WAN services. Several drafts presented at the IETF cover the way to signal and provision layer 2 virtual private network (L2 VPN) services based on an IP/MPLS infrastructure (see, e.g., Kompella et al., xe2x80x9cMPLS-based Layer 2 VPNsxe2x80x9d, Internet Draft, draft-kompella-ppvpn-12vpn-00.txt, published in June 2001 by the IETF).
As specified in the IEEE standard 802.1Q approved in December 1998, Ethernet networks may support one or more Virtual Local Area Networks (VLANs). An Ethernet frame circulating in such a network may include, after the Medium Access Control (MAC) address, an additional field called tag header or Q-tag which contains a VLAN identifier (VID). Accordingly, a VLAN-aware Ethernet bridge has the ability to perform frame switching based on the VID, deduced either from the physical port from which the incoming frame is received or from the contents of its tag header. A VLAN is used for the layer 2 broadcasting and forwarding of frames within a sub-group of users (subscribers of that VLAN). For example, in a corporation, it is possible to define respective virtual LANs for various departments to enable selective broadcasting and forwarding of information in the layer 2 procedures.
It has been suggested that the concept of VLAN can be extended in the case where Ethernet traffic is transported over a MPLS network (see, e.g., Martini et al., xe2x80x9cTransport of Layer 2 Frames Over MPLSxe2x80x9d, Internet Draft, draft-martini-12circuit-trans-mpls-08.txt, published in July 2001 by the IETF).
In such a case, a specific MPLS virtual connection, or LSP, originating at a PE can be associated with each VLAN to forward the frames intended for subscribers of that VLAN. The CE sends tagged frames to the PE and the latter switches them to the relevant virtual connections based on the ingress physical port and the VID.
Because Ethernet media were designed from the beginning as a LAN technology, they do not provide the signaling mechanisms required for WAN SVC networks. So establishing Ethernet PVC across a WAN network requires provisioning in both PE and CE devices.
Many parameters must be provisioned and stored especially in the PE device to allow a L2 VPN service.
An object of the present invention is to alleviate these provisioning issues.
Another object is to provide simplified signaling and set-up procedures for virtual connections between VLANs.
The invention proposes a method of providing a VPN service through a shared network infrastructure comprising a plurality of interconnected PE devices having CE interfaces. Some of the CE interfaces are allocated to a VPN supporting a plurality of VLANs and are arranged for exchanging traffic data units with respective CE devices, each traffic data unit including a VLAN identifier. The method comprises the step of:
establishing at least one virtual connection (VC) in the shared network infrastructure between two CE interfaces allocated to said VPN, for forwarding traffic data units including a respective VLAN identifier.
According to the invention, said VC has an identifier determined from said VLAN identifier and an identifier of said VPN.
In this way, it is not necessary to provide each PE device manually with VC identifiers for each CE interface. By the invention, a VC identifier is indeed directly derived from a known VPN identifier and a VLAN identifier known or discovered by a PE device. It thus simplifies the configuration of the PE devices by limiting the number of parameters values to be entered in their configuration table.
Such method does not cause identification ambiguity because the VPN service must precisely virtually connect two or more CE devices of a same VLAN within a VPN. So, the use, on the shared network infrastructure, of a virtual connection identifier that is based on VPN and VLAN identifiers is well adapted.
It even avoids interconnections of CE devices that would belong to different VLANs, whereas this can occur when provisioning the VC identifiers independently of the VLANs.
Advantageously, the VC identifier can be a code that directly contains concatenated VPN and VLAN identifiers.
In a preferred embodiment of the invention, the VCs are labeled switched paths (LSPs) of a MPLS architecture supported by the shared network infrastructure. However, other types of carrier networks can be used to provide a L2 VPN service in accordance with the invention, on the condition they comprise an addressing field for containing a VC identifier.
In case of a MPLS architecture, the PE devices are LERs (Label Edge Routers) and a virtual connection between two CE interfaces of two respective PE devices can be set-up with an appropriate protocol, like LDP (Label Distribution Protocol).
Another aspect of the invention relates to a method of establishing a VC between PE devices, for transporting traffic data units pertaining to a VLAN supported by a VPN, wherein said VPN comprises CE devices each connected to a respective PE device, wherein the VC has an identifier determined from an identifier of said VLAN and an identifier of said VPN.
Another aspect of the invention relates to a PE device comprising:
means for interconnecting to a shared network infrastructure;
at least one CE interface allocated to a VPN supporting a plurality of VLANs, arranged for exchanging traffic data units with a respective CE device, each traffic data unit including a VLAN identifier; and
means for establishing at least one VC between a first CE interface of said PE device and a second CE interface of another PE device interconnected to the shared network infrastructure, for forwarding traffic data units including a respective VLAN identifier, wherein the VC has an identifier determined from said VLAN identifier and an identifier of said VPN.
The preferred features of the above aspects which are indicated by the dependent claims may be combined as appropriate, and may be combined with any of the above aspects of the invention, as would be apparent to a person skilled in the art.